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The Specification 

Please amend the paragraph beginning on Page 8, Line 2 as follows: 

FIGURE 1 illustrates an exemplary business scenario 10 involving first LSP 12a, end- 
user customer 14 of first LSP 12a, and second LSP 12b. Business scenario 10 is used to 
describe the general process of mapping information according to the present invention from 
a Product Service Request (PSR) or another end-user order to an LSR or another inter- 
provider order in connection with switching residential line service for the end-user 14 from 
LSPa LSP 12a to LSP 12b. Li this example, end-user 14 has existing residential line service 
through the first (old) LSP 12a, which might be an ILEC, and is transferring this residential 
line service to the second (new) LSP 12b, which might be a CLEC. Existing residential line 
service is being provided through first LSP 12a over local loop 16 between end-user 14 and 
an appropriate port 18 of first LSP 12a. 

Please amend the paragraph beginning on Page 8, Line 31 as follows: 

FIGURE 2 illustrates exemplary system 30 for mapping certain information collected 
in connection with creation of PSRs or other end-user orders to LSRs or other inter-provider 
orders. Although PSRs and LSRs are primarily described, the present invention contemplates 
any appropriate end-user orders and inter-provider orders, respectively. System 30 includes a 
PSR ordering module 32, an associated user 34a, an LSR ordering module 36, and an 
associated user 34b. PSR ordering module 32 and LSR ordering module 36 may be integral 
to or separate from each other, in whole or in part, and may communicate with each other 
using any suitable wireline, wireless, or other communications link 38. Moreover, users 34a 
and 34b may be the same or different users 34. The components of PSR ordering module 32 
and LSR ordering module 36 may operate on one or more computer systems at one or more 
locations and may share one or more appropriate resources or constructs. For example, the 
PSR and LSR ordering modules 32 and 31 32 and 36 , respectively, may share the same 
database schema. In general, the user 34a interacts with the end-user 14 and creates a PSR 40 
using the PSR ordering module 32 and communicates information collected on the PSR 40 to 
LSR ordering module 36. User 34b uses LSR ordering module 36 to create a corresponding 
LSR 42 to effect provisioning of the service items requested by end-user 14. 
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Please amend the paragraph beginning on Page 9, Line 16 as follows: 

FIGURE 3 illustrates exemplary item type hierarchy 50, product specification 
hierarchy 52, and product catalog hierarchy 54 and relationships that exist between the 
elements of hierarchies 30, 32, and 31 50. 52, and 54 . In this example, item type hierarchy 50 
contains service item types 56 corresponding to line products that an LSP 12 may provide 
and market to end-users 14. The hierarchy 50 contains "Line Product" item type 56 at a first 
level 58, "Line" item type 56 (a subset of the "Line Product" item type 56) at a second level 
60, and "Option" and "MapLSRPort" item types 56 (both subsets of "Line" item type 56) at a 
third level 62. In general, item types 56 within hierarchy 50 form the foundation on which 
product specification hierarchy 52 and product catalog hierarchy 54 are constructed. While ) 
only a portion of hierarchy 50 corresponding to exemplary line products is described, those 
skilled in the art will appreciate that the present invention contemplates any suitable item 
types 56. For example, item types 56 in complete hierarchy 50 may additionally include, 
without limitation, "Trunk Product," "Non-Premise Product," "Line Option," "Key Option," 
"Product Option," "Business Set," "Flow through Command," "Flow through Plan," and any 
other appropriate item types 56. 

Please amend the paragraph beginning on Page 13, Line 31 as follows: 

The availabihty of DDLs 80 provides desirable extensibility to the PSR to LSR 
mapping process. For example, if the industry mandates that LSRs 42 should from some date 
forward include one or more additional fields requiring values, then the developer of PSR 
ordering engin e module 32 can readily associate one or more suitable DDLs 80 with 
appropriate item types 56 within hierarchy 50 to accommodate these additional fields. The 
LSP 12 is then able to map these DDL values, once collected during the PSR creation stage, 
through to the subsequent LSR creation stage. As a result, despite these additional fields, the 
LSP 12 is still able to reduce or eliminate multiple contacts with end-users 14. Nor will LSP 
12 be required to purchase an entirely new PSR ordering e ngin e module 32 or LSR ordering 
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engin e 3 4 module 36 to obtain these benefits. DDLs 80 provide a measure of future-proofing 
not available using prior techniques. 

Please amend the paragraph beginning on Page 14, Line 10 as follows: 

Analogous to item type hierarchy 50, product specification hierarchy 52, and service 
item hierarchy 54 described above in connection with PSRs 40, there exist hierarchies of 
items types, product specifications, and service items associated with creating LSRs 42. 
However, LSR related hierarchies are not in general the same as the corresponding PSR 
related hierarchies 30, 32, and 31 50. 52, and 54 . The LSR hierarchies are industry 
mandated, are not customizable for particular developers or LSPs 12, and specify the 
exhaustive set of service items that can be ordered through an LSR 42 (and the exhaustive set 
of corresponding product specifications and item types on which the service items are based). 
Thus, as illustrated in FIGURE 4, an LSR item type hierarchy 90 may include "LSRNum" 
and "LSReqType" item types 92 at level 94 analogous to "Line Product" item type 56 at level 
58 in PSR item type hierarchy 50, may include "Lnum" item type 92 at level 96 analogous to 
"Line" item type 56 at level 60 in PSR item type hierarchy 50, and may further include 
"Blocking" and "MapLSRPort" item types 92 at level 98 analogous to "Option" and 
"MapLSRPort" item types 56 at level 62 in PSR item type hierarchy 50. Although not 
explicitly shown, LSR product specification hierarchy 100 and product catalog hierarchy 102 
may include product specifications 104 and service items 106, respectively, that are 
analogous to PSR product specification hierarchy 52 and product catalog hierarchy 54, 
respectively, described above. 

Please amend the paragraph beginning on Page 14, Line 29 as follows: 

Accordingly, the PSR and LSR ordering modules 32 and 34 32 and 36 , respectively, 
used to create PSRs 40 and LSRs 42, respectively, have overlapping although not matching 
hierarchical data structures. For mapping of a DDL 80 associated with a PSR service item 72 
through to an LSR service item 106, these differing PSR and LSR data structures must have 
in common the item type 56 that is associated with DDL 80 - that is, the item type 56 in the 
PSR item type hierarchy 50 having DDL 80 must have a corresponding item type 92 in LSR 
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item type hierarchy 90. FIGURE 5 illustrates exemplary mapping between PSR and LSR 
item type hierarchies 30 and 70, respectively. As indicated by arrows 1 10 and 112, "Option" 
and "MapLSRPort" item types 56, respectively, are linked to "Line" item type 56 in the PSR 
item type hierarchy 50. As indicated by arrows 1 14 and 1 16, "Blocking" and "MapLSRPort" 
item types 92, respectively, are linked to "LNum" item type 92 in LSR item type hierarchy 
90. In this particular example, only "MapLSRPort" item typ e 56, 72 type 56, 92 is common 
to both hierarchies 30 and 70 50 and 90 such that the associated DDLs 80 can be mapped 
from PSR 40 to LSR 42. Since "Option" item type 56 is not linked to the "Lnum" item type 
92, however, there is no mapping from PSR 40 to LSR 42 for "Option" item type 56. As 
explained above, the specific item typ e 56, 72 type 56, 92 described herein are exemplary and 
provided for purposes of illustration. Those skilled in the art will readily appreciate that the 
present invention encompasses mapping of any suitable DDL 80 from PSR 40 to LSR 42 in 
relation to any associated item type 56, 72, according to particular needs. 

Please amend the paragraph beginning on Page 15, Line 17 as follows: 

In operation, assume that an end-user 14 has requested an unbundled port in 
connection with a residential service dialtone line. In one embodiment, a customer service 
representative handling the end-user request for LSP 12 uses a suitable user interface 
associated with PSR ordering engin e module 32 to navigate to or otherwise select 
"Residential Service" service item 72 from the product catalog of the LSP 12. In response to 
selection of "Residential Service" service item 72, user 34a is given the opportunity to 
navigate to or otherwise select "Dialtone Line" service item 72 and then "Unbundled Port" 
service item 72. In response, PSR ordering engin e module 32 then determines whether 
"Unbundled Port" service item 72 can be related back through "LSR Port" product 
specification 64 to "MapLSRPort" item type 56. In this case, "Unbundled Port" service item 
72 does relate back to "MapLSRPort" item type 56. PSR ordering e ngin e module 32 therefore 
determines that values associated with DDLs 80 need to be collected and prompts user 34a to 
supply the DDL values. In this case, user 34a would be prompted to collect from end-user 14 
and supply the LEAN and LEATN values for later mapping through to the LSR creation 
stage. As described above, the collection of these DDL values during the PSR creation stage 
reduces or eliminates the need for LSP personnel to contact the end-user 14 again during the 
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subsequent LSR creation stage to obtain these values, which provides an important technical 
advantage. 

Please amend the paragraph beginning on Page 16, Line 3 as follows: 

In one embodiment, PSR ordering engine 32 may validate that appropriate DDL 
values (such as the LEAN and LEATN values) have been properly supplied before accepting 
PSR 40 as completed, even though these DDL values may not be required until the LSR 
creation stage. PSR ordering engkie module 32 communicates the completed PSR 40 to the 
LSR ordering e ngin e module 36 for creation of a suitable LSR 42 based on PSR 40. At least 
some information on PSR 40 is mapped through to the LSR 42. In addition, DDL values 
collected during the PSR creation stage (but not needed for PSR 40 itself) are mapped 
through to the LSR 42. In practice, the LSRs 42 to which DDL values are mapped may 
include multiple separate forms, each of which includes one or more fields populated with 
these DDL values. For example, LSR 42 typically includes three forms - a "Port Services" 
form containing service specific information, a "Local Service Request" form that contains 
administrative information, and an "End User" form containing end-user related information. 

Please amend the paragraph beginning on Page 16, Line 16 as follows: 

In one embodiment, to map a DDL value collected at the PSR creation stage through 
to LSR 42, LSR ordering e ngin e module 36 evaluates each service item 72 on the PSR 40 to 
determine whether the service item 72 can be related back to an item type 56 in PSR item 
type hierarchy 50 with which DDL 80 is associated. If so, the LSR ordering e ngin e module 
36 maps the DDL value to a service item 106 contained on the LSR 42 that corresponds to 
service item 72. The mapping between service item 72 and service item 106 may be 
according to any suitable pre-defined mapping relationship, according to particular needs. 
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